Skip to content
This repository has been archived by the owner on Jun 4, 2024. It is now read-only.

Remove events #89

Merged
merged 15 commits into from
Jan 15, 2019
Merged

Remove events #89

merged 15 commits into from
Jan 15, 2019

Conversation

alexcjohnson
Copy link
Collaborator

Closes #88
Pretty simple in this repo - components already have n_clicks matching the click event, the only one provided here, so there's really no concern about removing it. Note that rebuilding was done using an updated version of dash, in its own no-events branch (which I haven't published yet). But I did a few other little things while I was in here:

  • Added a shortcut to run the tests from npm run test 173510e - unless I'm missing something and there already is an easy way to run them all?
  • There were lots of duplicates in elements.txt - I sorted and deduped them 2f873da
  • A little linting

package.json Outdated
@@ -26,7 +26,8 @@
"build:js-dev": "webpack --mode development",
"build:py": "node ./extract-meta src/components > dash_html_components/metadata.json && cp package.json dash_html_components && npm run generate-python-classes",
"build:all": "npm run build:js && npm run build:js-dev && npm run build:py",
"build:watch": "watch 'npm run build:all' src"
"build:watch": "watch 'npm run build:all' src",
"test": "python -m unittest tests.test_dash_html_components && python -m unittest tests.test_integration && python -m unittest tests.test_dash_import"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's update the circleci config to also use this.

python -m unittest tests.test_dash_html_components

@@ -192,7 +192,7 @@ if (!listPath) {
const list = fs
.readFileSync(listPath, 'utf8')
.split('\n')
.filter(item => !!item);
.filter(item => Boolean(item));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While at it, please add the npm run lint command to the CI Build step

Copy link
Contributor

@Marc-Andre-Rivet Marc-Andre-Rivet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two small tweaks, otherwise lgtm

@Marc-Andre-Rivet
Copy link
Contributor

Please create the master -> release-v1 merge after this.

python -m unittest tests.test_integration
python -m unittest tests.test_dash_import
npm run test
npm run lint
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd do the opposite and have linting run as early as possible (before npm run clean), to prevent executing a long-ish build and tests for nothing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or in this case, I guess the .js files are also generated -- so after the generation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to prevent executing a long-ish build and tests for nothing.

I could move it, but I wouldn't want linter errors to prevent running the rest of the tests. The tests aren't that expensive, seems to me it's worth knowing about all failures together. Personally linter errors are about the last thing I deal with - in the unusual case that they're not caught automatically by my editor, forcing me to fix them right away.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough for the ordering. I had scenarios like the table where running the tests takes up to 15 minutes :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I don't think you'll get all the errors as-is. If tests fail, the job will terminate before linting happens. You would need a job for tests and one for linting to always get both sources of failure.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Looks like we need a set +e perhaps? Personally I'd rather get all the errors even in cases where the tests take 15 minutes...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! That should also work.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, my bash-fu is not the best, but I couldn't find a straight shell solution that worked the way I wanted... everything I tried either stopped on first failure or ignored errors if something later passed. npm-run-all and its run-s command (with the -c option) behaves the way I wanted, running everything no matter what, and reporting an error from any part.

@alexcjohnson alexcjohnson merged commit 89a6d67 into master Jan 15, 2019
@alexcjohnson alexcjohnson deleted the no-events branch January 15, 2019 16:08
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants